Philipp Kern: Lazyweb question: How to avoid leaking process info?
Dear Lazyweb,
is there a simple way to block some users who login with SSH to read /proc/<pid>/cmdline of processes they don't own? Or better yet: don't see these pids at all?
I know that there are PID namespaces, but they seem to require a special PID 1. Seems hard to get for a simple SSH login. (I wouldn't mind changing a user's shell. But brittle shell startup scripts wouldn't cut it.) systemd-nspawn wants to boot a full Linux distribution in a container and even then I'd be unsure how to wire it up so that it cannot be skipped. I wouldn't mind a read-only bind mount of the outermost Linux installation into a chroot environment, as long as the parent SSH process can get the user jailed into it securely. (No need for someone to be root in the chroot.)
I know that there are RBAC frameworks, but they're cumbersome to use. I don't need file labelling or path-based access control, as I do trust the Linux file permissions for this. I think SMACK wouldn't help here, AppArmor isn't really useable in Debian testing and TOMOYO is a tad crazy to use with its domain transitions through process invocations.
I bet that grsecurity would have something for me up its sleeve. But it's not in a Debian kernel. Even though I know how to compile my own kernel I'd only do that if everything else fails.
Thanks in advance for your help.
UPDATE: That was quick, thanks to everyone who participated! Vasiliy Kulikov came up with a kernel patch to my problem (a hidepid mount option for procfs) that landed in 3.3. I tested it with the kernel in experimental and it works just fine and as expected. With hidepid set to 1, it will still leak the process count and their euids and egids. With hidepid set to 2, you only see your own processes, unless you're root. For ps there's no visible distinction between the two. So to test it you can just invoke this as root on a host running 3.3+:
is there a simple way to block some users who login with SSH to read /proc/<pid>/cmdline of processes they don't own? Or better yet: don't see these pids at all?
I know that there are PID namespaces, but they seem to require a special PID 1. Seems hard to get for a simple SSH login. (I wouldn't mind changing a user's shell. But brittle shell startup scripts wouldn't cut it.) systemd-nspawn wants to boot a full Linux distribution in a container and even then I'd be unsure how to wire it up so that it cannot be skipped. I wouldn't mind a read-only bind mount of the outermost Linux installation into a chroot environment, as long as the parent SSH process can get the user jailed into it securely. (No need for someone to be root in the chroot.)
I know that there are RBAC frameworks, but they're cumbersome to use. I don't need file labelling or path-based access control, as I do trust the Linux file permissions for this. I think SMACK wouldn't help here, AppArmor isn't really useable in Debian testing and TOMOYO is a tad crazy to use with its domain transitions through process invocations.
I bet that grsecurity would have something for me up its sleeve. But it's not in a Debian kernel. Even though I know how to compile my own kernel I'd only do that if everything else fails.
Thanks in advance for your help.
UPDATE: That was quick, thanks to everyone who participated! Vasiliy Kulikov came up with a kernel patch to my problem (a hidepid mount option for procfs) that landed in 3.3. I tested it with the kernel in experimental and it works just fine and as expected. With hidepid set to 1, it will still leak the process count and their euids and egids. With hidepid set to 2, you only see your own processes, unless you're root. For ps there's no visible distinction between the two. So to test it you can just invoke this as root on a host running 3.3+:
mount -o remount,hidepid=1 /procThere's even a backport request in the Debian BTS to get the feature into the wheezy kernel (3.2).